chore: Define backport criteria#22766
Conversation
github-actions
Bot
added
the
documentation
| ### Behavior changes | ||
|
|
||
| A "behavior change" is any fix that alters user-visible results: SQL | ||
| semantics (values, ordering, types, null handling), error messages that |
There was a problem hiding this comment.
I think we have made error message changes in minor releases before and it seems like that would be ok to me, to be honest.
The rest of this sounds good
| returning different results. Before opening the backport PR: | ||
|
|
||
| 1. State on the release tracking issue _why_ the change must ship in this | ||
| patch release rather than the next major. | ||
| 2. Describe the previous and new behavior with example queries and results. | ||
| 3. Wait for explicit acknowledgment from the release manager or another | ||
| committer on the tracking issue. |
There was a problem hiding this comment.
I am not sure we need to gate the creation of a backport PR on acknowledgement from the release manager -- making the backport PR is pretty simple, and I would expect that 2. (describing previous behavior, etc) would have already been done on the main issue
Explaining why you want the change in the patch release is a good idea though.
|
|
||
| ### Who decides | ||
|
|
||
| The release manager for the active release line is the final reviewer of |
There was a problem hiding this comment.
I think practically any committer can commit to a release branch too -- so maybe we can make ti clear that others can merge PRs to the release branch, though the release manager will review them
| DataFusion does not maintain Long-Term Support branches. In general only the | ||
| most recent `branch-NN` is actively maintained for backports. A branch is | ||
| considered closed once the next major release branch has been cut and the | ||
| release manager closes its tracking issue; users who need a fix beyond that | ||
| point should upgrade to the next major. | ||
|
|
||
| Security fixes are an exception: a maintainer may choose to backport a | ||
| critical security fix to an older branch even after it would otherwise be | ||
| closed. Discuss on the dev list or in a tracking issue before doing so. |
There was a problem hiding this comment.
This is true, but I also don't think I have heard opposition to doing more releases -- it is more of a bandwidth thing. Maybe we can soften the language a little like this:
| DataFusion does not maintain Long-Term Support branches. In general only the | |
| most recent `branch-NN` is actively maintained for backports. A branch is | |
| considered closed once the next major release branch has been cut and the | |
| release manager closes its tracking issue; users who need a fix beyond that | |
| point should upgrade to the next major. | |
| Security fixes are an exception: a maintainer may choose to backport a | |
| critical security fix to an older branch even after it would otherwise be | |
| closed. Discuss on the dev list or in a tracking issue before doing so. | |
| DataFusion does not maintain Long-Term Support branches. In general only the | |
| most recent `branch-NN` is actively maintained for backports, but if you need fixes in | |
| older releases, we are open to discussion. | |
| Security fixes are an exception: a maintainer may choose to backport a | |
| critical security fix to an older branch even after it would otherwise be | |
| closed. Discuss on the dev list or in a tracking issue before doing so. |
2 participants
Which issue does this PR close?
Rationale for this change
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?